Answer: No, volume 2 of the 5th edition already covers JDK 1.4. The
7th edition (with both volumes 1 and 2 updated) covers JDK 5.0.
Answer:
Answer: No.
Answer: The 7th edition uses JDK 5.0.
Answer: Unfortunately no. There are numerous revisions in all chapters, so it isn't just a matter of giving out the new chapters for free. We looked at offering a rebate if you turn in your old copy to the bookstore, but the bookstores balked at that.
Answer: It really doesn't matter, does it? Java is cross-platform. At any rate, after some readers complained on Amazon.com that the book is “Windows-centric”, I took all screen shots on Linux and changed all backslashes in path names to forward slashes. Those were the only “Windows-centric” aspects of the book, but apparently they were enough to offend the purists.
Answer: It really doesn't matter, does it? Java is cross-platform. At any rate, after some readers complained on Amazon.com that the book is “Windows-centric”, I took all screen shots on Linux and changed all backslashes in path names to forward slashes. Those were the only “Windows-centric” aspects of the book, but apparently they were enough to offend the purists.
Answer: Under Windows, select the MS-DOS Prompt or Command Prompt application from the start menu. There are many tutorials on the net—you may want to search Google to find one that you like.
On Mac OS X, run the Terminal application.
Answer: The javac compiler sends error messages to the standard error stream, not the standard output stream. Unfortunately, the Windows 9x/ME shell does not allow redirection of the standard error stream to a file.
Remedy: Use the errout.exe program to redirect the standard error stream to the standard output stream:
errout javac MyProg.java | more
errout javac MyProg.java > errors.txt
This is a simple C program--source code below:
#include <io.h>
#include <stdio.h>
#include <process.h>
int main(int argc, char* argv[])
{
dup2(1, 2); // make stderr go to stdout
execvp(argv[1], argv + 1);
return 0;
}
Or, if you prefer a pure Java solution, compile the following Java class:
import java.io.*;
public class Errout
{
public static void main(String[] args) throws IOException
{
Process p = Runtime.getRuntime().exec(args);
BufferedReader err
= new BufferedReader(new InputStreamReader(p.getErrorStream()));
String line;
while ((line = err.readLine()) != null)
System.out.println(line);
}
}
Then execute the following command:
java Errout javac MyProg.java | more
java Errout javac MyProg.java > errors.txt
Answer: It is the path and/or class path.
Do the following. First, deactivate any Java installation that you may have. That is, temporarily remove Café, the JDK you downloaded yesterday, the beta test of the nifty new environment that your brother in law gave you, etc. Install the SDK from the Sun web site. Download the Core Java files from the Prentice-Hall web site. Set the path and remove any class path settings. Reboot. Double-check that the class path is either unset or contains the current directory (.). Keep trying. This stuff always works out eventually.
Sun put out detailed installation instructions and an excellent tutorial that walks Windows users through all the steps in excruciating detail.
I have had to deal with dozens of users who swore that they did everything right, except they sheepishly admitted a couple of emails later that they didn't pay attention to capitalization, thought that there was no essential difference between a ; and a :, thought it was ok to add a few spaces to "improve" on the looks of the class path, didn't want to go through the trouble of deactivating their old version of Java, or whatever. Please: If the Java interpreter can't find some or all of the classes, check your path and class path, and don't report it as an error. Thanks!
Answer: In JDK 1.2 and above, this can happen if you have a class path but you forget to add the current directory (.) into it. This is because system classes (the ones in rt.jar) are always part of the class path. The current directory is also automatically searched if no explicit class path is provided. However, if an explicit class path is provided, the current directory is automatically searched by javac but not by java.
Answer: Please contact the vendor, Helios Software.
Answer: You need to install the Java Plug-in to run Java 2 applets in Netscape 4 or Internet Explorer. Netscape 6 and above, Mozilla, and Opera, have versions that include the Java Plug-in.
SQL Exception:
SQL State:08001
Message:No Suitable Driver
Vendor:0
Answer: You need to install a database and a JDBC driver and then edit the MakeDB.properties file to reference your driver. You also may need to change the class path to include the location of your driver. For instructions, please refer to the documentation from your database vendor.
Answer: The RMI setup is complex and it is very easy to get some detail wrong. Also, remember to always erase unneeded class files and to restart the naming service whenever you make a change in the configuration. Keep trying--it'll work eventually.
Answer: Install the Java SDK and use the jar program: jar xvf corejava.zip.
The Format class
is now available under LGPL. But, of course, as of JDK 5.0, you can just use
printf!
Answer: The warning is: "Method boolean isActive() in class AppletFrame does not override the corresponding method in class java.awt.Window. If you are trying to override this method, you cannot do so because it is private to a different package."
Oddly enough, there is a package visible method isActive in the Window class that I neither knew nor cared about--I must override the public isActive method in the AppletStub interface. The warning says that if I am trying to override the former, I will not succeed. That is fine with me. What is interesting is that the AppletFrame class now has two methods with identical name and signature, but different visibility. If its isActive method is ever called by any method defined by a class in the java.awt package, then that refers to the original Window.isActive method. However, if it is called by any other method, then it refers to the AppletFrame.isActive method.
This shows an interesting usage for package visibility. Had isActive been a public method, then I would not have been able to meaningfully extend from Frame and implement AppletStub --there would not have been one appropriate implementation of isActive for both. By giving isActive package visibility, it can be called by other classes in the java.awt package (it is actually called twice, by Container.proxyRequestFocus and Component.ensureWindowActivation ), and I can still construct subclasses that mix in interfaces with the same method name.